home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1993
/
Internet Info CD-ROM (Walnut Creek) (1993).iso
/
inet
/
internet-drafts
/
draft-vaudreuil-smtp-binary-00.txt
< prev
next >
Wrap
Text File
|
1993-10-18
|
12KB
|
303 lines
Network Working Group Greg Vaudreuil
Internet Draft Tigon Corporation
Expires: 4/18/94 October 18, 1993
SMTP Service Extensions
for High Performance and Binary Transmission
of Large MIME Messages
<draft-vaudreuil-smtp-binary-00.txt>
1.Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet Drafts as reference material or to cite
them other than as a "work in progress".
2.Abstract
This memo defines an extension to the SMTP service whereby an SMTP
client and server may negotiate the use of an alternate DATA command
"BDAT" for large potentially binary objects. Further, this option
will signal the ability of the server SMTP receiver to accept the
streaming of all commands up to the data command.
3.Introduction
The MIME extensions to the Internet message protocol provide for the
transmission of many kinds of data which were previously unsupported
in Internet mail. One expected result of the use of MIME is that SMTP
will be expected to carry very large mail messages, often into the
megabytes. There is a need avoid the overhead of base64 and quoted-
printable encoding of binary objects sent using the MIME message
format over SMTP including the requirement that the message be scanned
for "CR LF . CR LF" sequences upon sending.
A second source of inefficiency in the use of SMTP is the implicit
requirement to send the full SMTP command stream, including each RCPT
TO command sychronously, that is, to wait for a response to the
previous command before sending the next. This stop and wait
interaction often adds minutes to the length of a SMTP session, partly
by requiring validation of addresses one at a time.
This memo uses the mechanism defined in [4] to define extensions to
the SMTP service whereby a client ("sender-SMTP") may declare support
for the streaming SMTP implementation model and the BDAT command.
Internet Draft Expires 4/18/94
4.Framework for the High Performance Extensions
The following service extension is hereby defined:
1) The name of the service extension is "High Performance Binary"
2) The EHLO keyword value associated with this extension is "HP-
BINARY"
3) No parameter is used with the HP-BINARY keyword
4) One additional parameter to the BODY keyword defined [5] for
the MAIL FROM command is defined, "BINARYMIME". The value
"BINARYMIME" associated with this parameter indicates that this
message is a Binary MIME message (in strict compliance with [3])
with arbitrary octet content is being sent. The revised syntax of
the value is as follows, using the ABNF notation of [2]:
body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
5) A new SMTP verb is defined "BDAT" as a replacement for the
"DATA" command of [1]
5.The High Performance Binary service extension
When a client SMTP wishes to submit (using the MAIL command) a content
body consisting of a MIME message containing arbitrary octet-aligned
material, it first issues the EHLO command to the server SMTP. If the
server SMTP responds with code 250 to the EHLO command, and the
response includes the EHLO keyword value HP-BINARY, then the server
SMTP is indicating that it supports the extended MAIL command and will
accept MIME messages containing arbitrary octet-aligned material.
The extended MAIL command is issued by a client SMTP when it wishes to
transmit a content body consisting of a MIME message containing
arbitrary octet-aligned material. The syntax for this command is
identical to the MAIL command in [1], except that a BODY parameter
must appear after the address.
The complete syntax of this extended command is defined in [4]. The
ESMTP-keyword is BODY and the syntax for ESMTP-value is given by the
syntax for body-value shown above. A server which supports the HP-
BINARY transport service extension shall preserve all bits in each
octet passed using the DATA command.
After receiving the 250 response to the EHLO command with the HP-
BINARY keyword, the MAIL FROM and RCPT TO commands can optionally be
sent as a block. If the MAIL FROM address is invalid or otherwise
unavailable, the following RCPT TO commands should be answered with
the 503 command out of sequence error.
Note: While SMTP does not explicitly require the stop and wait
behavior, and while the protocol as defined will work in a
streaming model, the examples have led implementors to build SMTP
Vaudreuil [Page 2]
Internet Draft Expires 4/18/94
servers in such a manner as to require this behavior. This
service extension recognizes the desire to use a streaming
implementation model and explicitly encourages its use.
After all MAIL FROM and RCPT TO responses are collected and processed,
the BDAT command is sent. The BDAT command is a replacement for the
DATA command. The BDAT command takes one argument, the exact length
of the sent message in octets. After receiving the 354 reply code,
the message data is sent as a octet stream. Once the receiver-SMTP
receives the specified number of octets, it will return a 250 reply
code.
Note: The local storage size of a message may not accurately
reflect the actual size of the message sent due to local storage
conventions. In particular, text messages sent with the BDAT
command must be sent in the canonical CR LF terminated line
format.
If a server SMTP does not support the HP-BINARY transport extension
(either by not responding with code 250 to the EHLO command, or by not
including the EHLO keyword value HP-BINARY in its response), then the
client SMTP must not, under any circumstances, send binary data using
the DATA command.
If the receiver-SMTP does not support HP-BINARY and the message
content is a MIME object with a binary encoding, a client SMTP has two
options in this case: first, it may implement a gateway
transformation to convert the message into valid 7bit encoded MIME, or
second, it may treat this as a permanent error and handle it in the
usual manner for delivery failures. The specifics of the
transformation from Binary MIME to 7bit MIME are not described by this
RFC; the conversion is nevertheless constrained in the following ways:
(1) it must cause no loss of information; MIME transport
encodings must be employed as needed to insure this is the case,
and
(2) the resulting message must be valid 7bit MIME.
As of present there are no mechanisms for converting a binary MIME
object into a 8bit-MIME object. Such a transformation will require
the specification of a new MIME content-transfer-encoding, the
standardization of which is discouraged.
Vaudreuil [Page 3]
Internet Draft Expires 4/18/94
6.Usage Examples
The following dialogue illustrates the use of the High Performance and
Binary service extension to send a BINARY object to three recipients
without the stop and wait for an explicit 250 for each recipient:
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 cnri.reston.va.us SMTP service ready
C: EHLO ymir.claremont.edu
S: 250-cnri.reston.va.us says hello
S: 250 8BITMIME
S: 250 HP-BINARY
C: MAIL FROM:<ned@ymir.claremont.edu> BINARYMIME
S: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok
C: RCPT TO:<vcerf@cnri.reston.va.us>
C: RCPT TO:<gvaudre@cnri.reston.va.us>
C: RCPT TO:<jstewart@cnri.reston.va.us>
S: 250 <vcerf@cnri.reston.va.us>... Recipient ok
S: 250 <gvaudre@cnri.reston.va.us>... Recipient ok
S: 250 <jstewart@cnri.reston.va.us>... Recipient ok
C: BDAT 1324
S: 354 Send BINARYMIME message of 1324 Octets.
...
S: 250 OK
C: QUIT
S: 250 Goodbye
The following dialogue illustrates the use of the High Performance and
Binary service extension to send a large 7 bit plain text object to
one recipient without the dot-stuffing overhead of the DATA command:
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 cnri.reston.va.us SMTP service ready
C: EHLO ymir.claremont.edu
S: 250-cnri.reston.va.us says hello
S: 250 8BITMIME
S: 250 HP-BINARY
C: MAIL FROM:<ned@ymir.claremont.edu> BODY=7BIT
S: 250 <ned@ymir.claremont.edu>... Sender and 7BIT
C: RCPT TO:<vcerf@cnri.reston.va.us>
S: 250 <vcerf@cnri.reston.va.us>... Recipient ok
C: BDAT 1324
S: 354 Send 7BIT message of 78324 Octets.
...
S: 250 OK
C: QUIT
S: 250 Goodbye
Vaudreuil [Page 4]
Internet Draft Expires 4/18/94
7.Security Considerations
This RFC does not discuss security issues and is not believed to raise
any security issues not already endemic in electronic mail and present
in fully conforming implementations of [1].
8.Acknowledgements
This document is the result of numerous discussions in the IETF SMTP
Extensions Working Group and in particular due to the continued
advocacy of "chunking" by Neil Katin. Text for this document was
liberally copied from RFC 1426 by John Klensin, Marshall Rose, Ned
Freed, Dave Crocker, and Einar Stefferud.
9.References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
Extensions", RFC 1341, Bellcore, Innosoft, June 1992.
[4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC
1425,
[5] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-
MIMEtransport" RFC 1426, United Nations University, Innosoft
International, Inc., Dover Beach Consulting, Inc., Network
Management Associates, Inc., The Branch Office, February 1993.
10. Author's Address
Gregory M. Vaudreuil
The Tigon Corporation
17080 Dallas Parkway
Dallas, TX 75248-1905
214-733-2722
Gvaudre@cnri.reston.va.us
Vaudreuil [Page 5]